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ABSTRACT 

The Integrated Science Instrument Module (ISIM) for the James Webb Space Telescope (JWST) provides the critical 
functions and the environment for the four science instruments on JWST. This complex system development across 
many international organizations presents unique challenges and unique solutions. Here we describe how the 
requirement flow has been coordinated through the documentation system, how the tools and processes are used to 
minimize impact to the development of the affected interfaces, how the system design has matured, how the design 
review process operates, and how the system implementation is managed through reporting to ensure a truly world class 
scientific instrument compliment is created as the final product. 
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1. INTRODUCTION 

This paper describes the system engineering (SE) approach, methodology, road blocks, and work-arounds or adjustments 
experienced and applied to the ISIM element of the JWST and its subsystems. In general, it will explain the approach 
taken in developing or defining the architecture, a description of some of the problems encountered, and the solution or 
resolution to the problem. A modification to the NASA accepted system development V-process is presented as a 
realization of the idealized development process. 

JWST is a large space observatory built by NASA and planned to be launched on an Ariane launch vehicle in 2013. The 
JWST Observatory will perform and provide high resolution imagery and spectroscopy similar to the Hubble Space 
Telescope (HST). The JWST is essentially the replacement observatory of the HST, although the observing wavelength 
range of the JWST is longer than the HST. JWST consists of three major elements; the Optical Telescope Element 
(OTE), the Integrated Science Instrument Module (ISIM) Element and the Spacecraft Element. 

In general, the ISIM support systems provide the critical functions and the environment for the four science instruments 
on JWST. With each of the instruments being designed and built by a different organization, each having unique needs, 
each performing different functions, and all having interfaces spanning all regions of the observatory provides many 
technical and systems management challenges. In an environment where even small changes have big ripple effects and 
impacts to other hardware and organizations, the development of a consistent requirement flow system, requirements 
tracking, and system verification among multiple organizations is needed. The organizations include the NASA Goddard 
Space Flight Center (GSFC), Northrop Grumman Space Technologies (NGST), Jet Propulsion Laboratory (JPL), the 
European Space Agency (ESA), Canadian Space Agency (CSA), the European Consortium (EC), Ball Aerospace, 
University of Arizona, Lockheed Martin and Teledyne Imaging Systems. Throughout the development of JWST, the 
subsystems have varied greatly in their development levels and schedule needs. At this time, the JWST mission has just 
held its Preliminary Design Review (PDR); however, many of the instrument subsystems have held their Critical Design 
Review (CDR) several years prior. This span of development levels has lead to interesting challenges in the interface 
definition and system engineering of the subsystems. 

The ISIM is a distributed system that includes a cryogenic module containing the Science Instrument (SI) payload, a 
Fine Guidance Sensor (FGS), supporting structure, and passive thermal control systems. The ISIM system also includes 
an ISIM Command and Data Handling (ICDH) system and an ISIM Remote Services Unit (IRSU). The ICDH is located 
within the Spacecraft and the IRSU is located with other warm instrument electronics in the ISIM Electronics 
Compartment (IEC). The Sis include a Near-Infrared Camera (NIRCam), a Near-Infrared multi-object Spectrograph 
(NIRSpec), a Mid-Infrared Instrument (MIRI) and a Near-Infrared Tunable Filter Instrument (FGS-TFI). 



The NIRCam is a large field-of-view (FOV), broadband, high angular resolution imager and serves as both a science 
instrument on JWST and as the Optical Telescope Element’s wavefront sensor (WFS). The NIRCam covers a spectral 
range of 0.8-5 micrometers, has coronagraphic capabilities and has two independent modules with separate FOVs each 
incorporating a short wave and a long wave channel. 

NIRSpec is a multi-object dispersive spectrograph also covering a large field-of-view and capable of observing >100 
sources simultaneously. The sky is imaged by the telescope on the spectrograph aperture focal plane by a pick-off mirror 
and a system of foreoptics. Targets in the FOV are viewed by opening selected shutters in a micro-shutter array to form 
slits. These slits are re-imaged onto a mosaic of NIR detectors by a collimator, a dispersing element or an imaging 
mirror, and a camera. 

MIRI, unique as the only JWST mid- infrared instrument, comprises an Optical Module, a set of control electronics, 
flight software (FSW), and a Cryo-cooler with its own set of electronics and FSW. MIRI is to operate within the 
wavelength region between 5 to 28 pm and provide imaging, spectroscopy, and coronagraphy. The MIRI provides 
functionality which enables it to satisfy aspects of all four of the major science themes of the JWST. It differs mainly in 
the Cryo-Cooler interfaces, which span all three regions of the Observatory. Within the cold optical region of ISIM, the 
Cryo-cooler interfaces with the ISIM on mounting pads for the 18K heat exchanger and the coolant lines, and it 
interfaces to MIRI through a 6K heat exchanger on a single location on the MIRI optical bench. 

The Fine Guidance Sensor (FGS) serves as part of the Observatory line-of-sight control system as well as part of the 
Science instrument suite. The FGS comprises a Guider to provide telescope pointing and partial wave front sensing and a 
Tunable Filter Imager (FGS-TFI). The FGS hardware includes an optical assembly with a set of Focal Plane/Instrument 
Control Electronics Units and associated cables. The Optical Assembly of the FGS instrument consists of two 
independent optical imaging sub-systems. The Guider sub-system images two separate regions of the JWST field-of- 
view onto two independent focal plane arrays. These two channels are dedicated to the Spacecraft guider function. The 
second sub-system is the science imaging Tunable Filter sub-assembly, which consists of a single FOV that is imaged 
onto a focal plane array. The TFI features a tunable Fabry-Perot etalon allowing it to perform narrow-band imaging. 

ISIM structure is the support frame for all four of the Science Instrument and the associated support services. The main 
optical bench of each SI is mounted to the composite structure on struts, or kinematic mounts. These struts have 3 or 4 
interfaces on the ISIM structure and three on the SI benches. Although it was attempted to provide an ideal iso-static 
configuration to each SI, it was nearly impossible to find acceptable ISIM structure and SI mounting locations that would 
work. NIRCam’ s mounting struts are the least “ideally kinematic” of all of the Sis. NIRCam, however, includes a 
pickoff mirror with focus and tip-tilt capability and is therefore able to correct for bulk motions of the NIRCam Optical 
Assembly. MIRI is more tolerant of position and focus inaccuracies and does not employ an actuated pickoff mirror. 
NIRSpec and FGS are mounted on shorter struts and therefore less motion of these instruments is expected. These 
instruments both include focus adjustment on their pickoff mirrors to account for focus changes from ground to orbit as 
well as focus placement inaccuracies of the instruments in the ISIM structure. All of the Si’s struts include a flexure 
section and the optical benches are made of a light-weighted panel and rib assemblies that are not deformed by ISIM 
structure motions due to cool down or due to various gravity orientations experienced by ISIM throughout the JWST test 
program. 


2. ENGINEERING ORGANIZATION AND COMMUNICATION 

Imperative to the development of a large system such as the JWST and the ISIM Element is a well defined set of roles 
and responsibilities, a dedicated engineering team, and a consistent approach to the design and engineering challenges. 
Early on in the development of the ISIM engineering team, the set of responsibilities was defined. The ISIM element 
management structure consists of an ISIM manager, ISIM assistant manager, and a chief ISIM systems engineer. 
Principally, the instrument roles are defined as one key systems team member assigned to each instrument, with a wide 
array of discipline engineers to provide “cross-cutting” support. The discipline engineering includes mechanical, 
electrical, thermal, contamination, radiation, optical, operations, mechanisms, and cryogenics. In addition, other 
engineering support can be brought in on an as needed basis. These managers and systems engineers work as a team 
with the managers and engineers at the ISIM subsystem levels as well as the Observatory level engineers to ensure there 
is consistent requirement definition and work flow between the levels. 



NIRCam is the only fully-US-built instrument. GSFC/ISIM (consists of Instrument manager and SE) has a contract with 
the University of Arizona who has a prime contractor, Lockheed Martin, and a detector contractor, Telydyne Imaging 
Systems. The University of Arizona team mainly consists of PI, SE, Program manager and science/focal plane assembly 
team. Lockheed has many subcontracts, such as AxSys and Barr. 

As unique an architecture as MIRI has, it also has a very diverse and international engineering and management 
organization. It is supplied to NASA GSFC through ESA. However it is designed and built by JPL and EC. JPL supplies 
the Cryo-cooler, the detectors, the detector electronics, and the FSW. EC, which comprises ten countries and twenty-six 
organizations, supplies the optical bench assembly and mechanism electronics. It is managed by a management team 
with members from GSFC, JPL, EC, and ESA. 

NIRSpec has a similar managerial and organizational structures to MIRI. NIRSpec has a GSFC/ISIM Manager and 
Systems engineer. There are 3 components of NIRSpec, the NIRSpec Optical Assembly, which is provided by ESA, 
with ASTRIUM as the prime contractor, the NIRSpec Microshutter subsystem and its electronics, which is provided by 
GSFC, and the Detector subsystem including a focal plane housing, detectors and electronics, which is provided by 
GSFC. 

FGS has the simplest organizational structure, consisting of a GSFC/ISIM manager and system engineer with the 
instrument built and provided by the Canadian Space Agency and their prime contractor, COMDEV. 

Given that JWST and ISIM are such large international projects spanning nine time zones, the development of a strong 
and effective communications system was critical. The NASA/GSFC facility is the lead center for the ISIM system 
engineering team. To ensure requirement definition, problem identification, and resolution went as smoothly as possible, 
the ISIM system engineering and project team established a high bandwidth communication system early on. The goal 
of the systems engineering team has been to keep these forms of communication as open as possible. Communication 
channels have been established to all interfacing organizations - above and below - the ISIM team. This helps ensure 
that each product development team is aware of changes and problems within the system that may impact their system. 

Communication difficulties are overcome through multi-faceted communication paths. 

• E-mail and telephone calls to coordinate daily ordinary work 

• Weekly systems and discipline specific teleconferences 

• Weekly status reports 

• Monthly progress reviews (MSR) 

• Quarterly technical interchange meetings (TIM) 

• Partner workshops occurring 2-3 times per year 

• Various as-needed discipline specific meetings, such as Optical Summits 

• Regularly scheduled design reviews (Peer Reviews, SRR, PDR, CDR, MRR, Qual Reviews. . .etc.) 

• Next Generation Integrated Network (NGIN) - the JWST web-based document management system 

The benefits of face-to-face meetings cannot be disputed. Teleconferences do not convey the same level of involvement 
as attending a meeting in person. Even video-con meetings do not allow the same level of commitment and participation 
as a face-to-face meeting. The larger a meeting becomes the less effective the video or teleconference tie-in becomes. 

For things out of the daily, ordinary work there are teleconferences and special TIMs scheduled to deal with specific 
issues. There is always a constant web of information flow in order to keep up with the ongoing work, any changes, any 
issues, any improvements on the architecture or system wide impact of these to the development and schedule of other 
components. This allows for improvement on the reaction time on the issues, and a quick turn around on resolution. 

There are drawbacks, however, to this constant communication. The amount of information moving between all of the 
levels is overwhelming as is the task of disseminating the information and weighing its importance to the other 
subsystems and teams. With so many people in the loop, there can be an overreacting to issues that pop up initially that 
might not be issues at all. To avoid this, information must flow along the tiered system of management previously 
described. However, ISIM systems engineering frequently deals directly with the instrument prime contractor’s systems 
engineering team and this open communication path has been very effective in working through interface definition and 



requirement development. The difficulty has been the disconnect between the levels of system maturity. Since the Sis 
are ahead of the systems that they interface with, they are frequently asked to evaluate design solutions that assume 
flexibility in their design and architecture. This has been, and continues to be, a struggle. 

One example of the difficulty of working through the formal hierarchy chain is when dealing with the unique wavefront 
sensing interfaces of NIRCam. NIRCam is an ISIM subsystem and ISIM is a Government Furnished Equipment item to 
the JWST Prime Contractor, NGST. Ball is a subcontract to NGST. The Ball team and the Lockheed team have direct 
interfaces to each other as there are WFS components designed and built by Ball in the NIRCam instrument. The formal 
path of information flow is quite long. For example, if Ball would like to send information to the engineer working on 
the NIRCam filter wheel, which contains Ball-provided WFS components, the correct hierarchy would be: 

Ball’s WFS Component Engineer -> 

NGST’s JWST program management/SE -> 

GSFC’s JWST Observatory project management/SE-> 

GSFC’s ISIM Management/SE -> 

GSFC’s NIRCam Management/SE -> 

University of Arizona’s NIRCam Management/SE -> 

Lockheed Martin’s NIRCam Management/SE -> 

NIRCam Subsystem Engineer at Lockheed Martin. 

Although we keep all of the levels involved, the typical information flow tends to flow as: 

Ball’s WFS Component Engineer -> 

GSFC’s NIRCam Management/SE -> 

Lockheed Martin’s NIRCam Management/SE -> 

NIRCam Subsystem Engineer at Lockheed Martin. 

Which is still a slow path, but not as unrealistic as the formal path. 

A significant roadblock in effectiveness of JWST communication is the impact of the US International Traffic and Arms 
Regulations (ITAR). There have been numerous instances of the ITAR preventing the open flow of information because 
of a poor definition of what can be communicated and what cannot be communicated. These regulations have required 
that each US organization and US company obtain state department approval for communication and transfer of 
information with our international partners. Without this approval, many of the contractors and consultants interpreted 
the regulation as banning or prohibiting any communication whatsoever. Even with the agreed to documents and 
technical approval, it is still unclear what communication is acceptable. Rather than risk any repercussions, many NASA 
contractors have taken a no risk approach and have declared all documents, including schedules and requirements, 
associated with the JWST development as ITAR sensitive. 

3. REQUIREMENT GENERATION 

The configuration management process is central to the coordination of requirements between the Observatory, ISIM and 
the ISIM subsystems. Without the official “CM’ed” versions of the requirements, agreements are not binding. Even 
then, only CM’ed documents that are specific to the subsystem’s contract or statement of work of the instrument in 
question are binding to them. 

The JWST Project Configuration Management (CM) and Configuration Item (Cl) philosophy provides procedures and 
requirements for baseline documents, changes to baseline documents and drawing control. It is a process that is intended 
to ensure that all proposed and approved technical and programmatic changes to JWST hardware, software, ground 
support equipment (GSE), ground system, Science, Launch Vehicle interfaces, testing and verification, and associated 
documents and drawings are systematically evaluated for validity, merit, need, and impact. The JWST Project CM/CI is 
applicable to JWST Project and external organizations under direct contract to the JWST Project, including major out-of- 
house elements (e.g., contractor provided Observatory build and systems integration) and major in-house Government 
Furnished Equipment [GFE]. 

The Configuration Management process is regulated by GSFC standards. The process is formalized, documented and 
audited through the GSFC ISO system. This system requires that the documents under CM control be subjected to a 
rigorous Configuration Control Board (CCB) review process prior to initial release and then prior to any document 



revision releases. Through a controlled web-based data system, NGIN, the changes to an existing document are 
presented to all of the stakeholders. The stakeholders are able to review the changes and then accept, reject and provide 
comments to the proposed changes. The document owner then must use this data system to document and disposition 
comments. A change matrix is then provided to the stakeholders and a CCB meeting is held. Once concurrence is 
obtained, the changes are put into the Microsoft Word ™ version of the document using this software’s “redline” 
feature. The changes are then verified for agreement with the proposed changes and approved change matrix and a clean 
final version is completed. This version is sent to the signatories on the document for their final approval. Once all 
parties have signed the version of the document, the final release of the document version is generated as a “pdf’ and 
posted in the NGIN’s on-line library. This is the controlled version and any printout or electronic copy of this document 
is considered unofficial and obsolete. 

The ISIM systems engineering team found that the best way to keep the CM process simple and clear was to have the 
requirement negotiation with the instruments, or other subsystem, thoroughly worked through prior to submitting the 
document to CM. The Requirement Technical Coordination (RTC) process was developed to coordinate and track 
proposed changes to a document after the release of the initial “baseline” version prior to the submission of the change to 
the CCB. This RTC processing occurs outside and prior to the official CCB process and serves to streamline the 
regulated process and protect it from the excessive iterations needed to agree to requirement changes. 

Each proposed change, or similar group of changes, has its own RTC document that serves to document current and 
proposed requirement wording, the rationale for the changes as well as to document the process of negotiating of the 
change. The RTC shows the changes proposed to the specified requirements with “redline” text. Versions of the RTC 
document are kept to maintain a record of the process of change negotiation. The RTC goes through two series of 
reviews; one internal and one external, to ensure that all affected parties have reviewed and agreed to the change prior to 
CM. The final RTC document is submitted to CM for the final “official” review and change to the document. 

A database tool called the Dynamic Object Oriented Requirement System (DOORS) is being used in conjunction with 
the existing CM process, which is based on Microsoft Word™ and pdf documents. DOORS is one of the tools used to 
manage all of the requirements at the ISIM and Observatory level. It is very useful and effective in generating the links 
between documents of all levels to ensure that there are no broken links between requirements as well as helping with the 
trace of the verification activities. It can be versatile when utilized as a daily tool to work within modules and 
requirements directly to more efficiently handle changes to the documents. 

DOORS modules are not controlled by the CM, but are controlled by the authors. This means that the official document 
changes are not being handled through DOORS but are handled through NGIN, which adds extra steps to update 
documents, traces, verification matrices, and also audit these constantly to make sure that CM and DOORS are consistent 
with one another. For this reason the DOORS work always lags behind the actual systems engineering work, which 
renders the tools less effective. 

In order to avoid additional work and actually make the daily work more efficient, and eventually self sufficient to a 
certain degree, tools such as DOORS need to be used at the heart of the CM. As useful as it is, DOORS or tools like it 
need to be used to their full potential and need to be used by all groups and disciplines to be effective. It is anticipated 
that documents developed in DOORS, or similar tools, will eventually be used as the CM system for large NASA 
projects. It was attempted to use this system for the JWST CM system, but the NASA standards for CM, at the start of 
the JWST Program were not ready to accept this process, and given the international interfaces which are part of the 
JWST system, it would have been very difficult to impose DOORS as the CM. 

The requirement documents for the ISIM system and subsystems fall into one of four categories. These are performance 
requirements, interface requirements, mission assurance requirements, and deliverable items. Each of these types of 
documents serve their own purpose, but contain, as a whole, the full set of requirements each subsystem is expected to 
adhere to. As the name implies, the performance requirements specify key parameters such as wavelength operation, 
sensitivity, and efficiency. The interface requirements document specifies mass, power, interface loads, thermal 
conditions etc. The mission assurance requirements define the key quality assurance control measures to be 
implemented by the project. The deliverable items documents inform the developers all expected hardware, software, 
and reporting requirements. A requirement flow hierarchy and diagram has been developed to depict this flow. 



Requirement documents are owned by the organization that the requirements affect. The Mission Requirements 
Document (MRD) is owned and controlled by the JWST project. One child document to the MRD is the Observatory 
Specification. This document is owned and controlled by the NGST organization. The Observatory Specification serves 
as the parent document for the ISIM Requirements Document, which is owned and controlled by the ISIM team at 
GSFC. To handle the requirement flow with parent/child documents owned and controlled by different originations, 
each document contains the requirements at its own level and the child requirement for each level below it. For instance, 
the Observatory Specification contains the requirements on the Observatory and then on each of the three Observatory 
elements, including the ISIM Element. The ISIM Requirements Document then captures the same ISIM Element 
requirements verbatim from the Observatory Specification and then documents any child requirements on the ISIM 
subsystems. 

ISIM requirements come from the Observatory specification and the ISIM to OTE and Spacecraft Interface 
Requirements and Control Document (IOS). The requirements in these documents are negotiated between NGST, 
STScI and Goddard, with input from the other partners as needed. When changing a requirement, the RTC process 
includes all requirements affected at both higher and lower levels, at least down to the ISIM level. ISIM level 
requirements are then parsed as needed down to the thirteen ISIM subsystems. Many requirements, however, are not 
easy to separate into contributions from each subsystem and in these cases ISIM as a system will selectively choose to 
flow or not to flow certain requirements to the subsystems. There are also many instances where many ISIM-level 
requirements require only a single performance parameter for a subsystem. In this case, the ISIM-level requirements are 
in a many-to-one requirement flow situation. 

Examples of where this is done include image quality requirements, pointing requirements, redundancy requirements and 
timing requirements. For instance, in order to meet the ISIM-level image quality requirements, the ISIM structure, the 
FGS and the prime observing instrument all must have certain stability relative to each other. By levying the stability 
requirement for image motion on the subsystems, the ISIM is now also able to meet several ISIM-level pointing and 
calibration requirements. Creating the many-to-one requirement relationships in these cases insures that the impact on 
pointing and calibration is considered whenever the image quality requirements are modified. 

The instrument subsystems are considered long-lead items for the ISIM element and their development is therefore 
accelerated relative to the rest of the JWST project. Because of this, ISIM needed to define all of the instrument 
subsystem requirements before many of the higher-level requirements and other ISIM subsystem requirements were in 
place. In doing this, ISIM has locked into particular instrument designs early and has had to play a lead role in 
accommodating their design into a developing observatory. 

4. SYSTEM ENGINEERING PROCESS 

The NASA accepted System Engineering approach, documented in the NASA Program Guideline, NPG-7 123.1, follows 
the process depicted in Figure 1. This V process follows a three-phase approach; study phase, development phase, and 
the verification phase. Early in the program, in the study phase, the user needs are taken into account and concept studies 
are conducted. The requirements documents are written and iterated upon based on these. First preliminary, then 
detailed analyses and design tasks are completed. The available technologies are taken into account throughout these 
design iterations in order to insure a realistic solution to the mission need. During this definition, identified issues are 
iterated upon and fed-back to the previous step, which allows updating requirements, allocations, and the design. A 
series of design reviews are conducted during this definition phase as gates to ensure adequate design has occurred and 
before advancing into the next step. This Decomposition and Definition leg of the systems process is not isolated from 
the Integration and Verification leg. During the definition phase, the design and review team look forward to the 
verification efforts in anticipation of how the system verification will occur. This to make sure the system is testable and 
that test equipment is adequate. After successful completion of all design reviews, engineering units and qualification 
units are authorized for development. During the definition phase, any issues that are uncovered can be fed-back to the 
previous steps to update the design or ensure that the issues are understood and mitigated. In the second leg of the 
process the subsystem, segment, and the system level integration and verification tasks are conducted. Any waivers or 
issues are raised against the documentation, and reviewed through a board of expert engineers. Before each verification 
activity a Test Readiness Review (TRR) is conducted. After a successful Pre-Shipment Review (PSR) the product is 
delivered. 




Figure 1. Ideal V-chart describing system development. 

We argue that this general systems engineering process flow is an idealized approach for a system lifecycle. Below we 
present a set of realized process approaches experienced on ISIM, which is perhaps a unique, long-term project. 

The first flaw in the ideal approach is the feedback identified between the definition phase and the verification phase. 
We submit that the designers and developers during the definition phase should be looking forward to the verification 
phase to provide guidance in the development of a verifiable system, but in the NASA environment, the return to the 
definition phase, or looking back to the definition phase from the verification phase is uncommon. NASA projects are 
generally one of a kind systems with little to no recurring design. This feedback from verification to definition is more 
appropriate in high volume, or production environments. 

We also note an introduction or process for handling replans is necessary. A replan is an impulsive change to the 
system definition which can result from cost, schedule, or technical constraints. Given a replan at any point of the 
program, a similar process to the ideal process is followed to ensure that the end goal meets the changes intended by the 
replan, but leaves other system aspects unchanged and still feasible. At the point of the replan, shown in Figure 2, the 
changes are identified in detail. An impact assessment audit is conducted, which provides feedback to all of the 
requirements, analysis, design, integration, and verification processes. This assessment attempts to limit the impact to 
the lowest level of the definition phase, but must study and ensure limited or no impact to earlier levels of the definition. 
We note that even minor changes can have unintended and hidden impacts and the system engineering team’s role is to 
identify these impacts. Any issues are flagged and iterated upon. The changes are flowed through the entire system 





quickly and a new baseline is obtained. The rest of the work continues from where it was left off based on the new 
baseline. 



Figure 2. Ideal V-chart showing effect of replan on system development. 

Another aspect of the non-ideal nature of the process is the time phasing of the ISIM subsystems to the observatory. All 
four of the science instruments were completing the definition phase as the ISIM and observatory were just entering or 
still in the early phases of the definition. This was due to two primary reasons. Contractual review and award cycles of 
the observatory lagged the predicted time period resulting in a delayed start of the observatory definition. Also, the 
instruments were expected to be long lead items due to the technical readiness of their subsystems, and difficulties often 
encountered in manufacture of similar, but unique, precision engineered equipment. NIRCam and MIRI passed their 
CDRs two years prior to Mission-level PDR and the other two instruments are having their CDRs essentially concurrent 
with the Mission PDR. This was done to insure that the SI ETUs were ready in time for development testing of the ETU 
ISIM and the Optical Telescope pathfinder. The consequences of this early development are that the performance 
parameters of the instruments were defined before the Observatory was fully designed and that the interface of Sis to the 
Observatory and to other ISIM subsystems were determined before the other subsystem were defined. To accommodate 
this approach, many of the requirements had large amounts of margin built in to them to accommodate future changes. 
Items such as electrical power and thermal dissipation carried large margins early on. This proved to be successful as the 
instruments have been able to accommodate large changes in Observatory architecture without major design changes on 
their part. 




This approach has been taxing on the instruments. The SI teams have had to deal with a changing ISIM and Observatory 
and have had to participate in trade studies and working groups. These changes and studies would appear to the Sis as 
late, but to the ISIM and Observatory as properly timed. 



Figure 3. Schematic representation of systems engineering process used on JWST/ISIM. 

The nature of this staged development schedule is depicted in Figure 3. This figure shows how the instrument 
subsystems lead the ISIM and Observatory in design and build. As can be seen in figure, the early development of the 
instrument subsystems results in them seeing the development of each of the later subsystems as well as being exposed 
to replans at each level of assembly. 

An outcome is this realized W-process is that lower level components, such as the instruments, enter the build phase 
while higher level requirements are still being developed. This became apparent as the instruments started going through 
their PDRs and even CDRs before observatory or even ISIM itself has reached their PDR levels. Late changes to the 
instruments needed to be limited in order to avoid repeated analysis, redesigns, and schedule and cost impacts, which 
would eventually ripple through the rest of the project. This was achieved in several manners: 

• Perform certain analyses at ISIM level and develop requirements without parents, instead of waiting for 
higher level analyses and requirements development for things that have not yet been defined. 

• Keep additional margins on certain requirements that have been defined but have not yet been developed 
fully 

Re-plans are almost unavoidable, even if the above precautions are taken. The redesign could be caused by 
programmatic or technical reasons, but no matter what the cause is they will immensely affect the development of the 







products especially in the later design and development phases of the program. These have been avoided as much as 
possible with the instruments by several methods; 

• Keep the interfaces simple. This eliminates design interdependency of the components, which allow for 
more versatility in the design and avoids major changes during re-plans. 

• Keep healthy margins. This also ensures that requirements can still be met when the uncertainty on 
requirements and performance goes south because of the cuts in the program. 

• Perform as many of the tests as possible to verify component performance at lower levels. If planned 
properly even the interfaces can be verified at lower levels to a great degree of confidence, which has been 
done on all Sis by a fixture called the ASMIF, which replicated the flight footprint of the instruments on 
ISIM structure and equipped with alignment tools. 

ISIM itself has gone thru several redesigns and re-plans, most of which have been endured without major changes to the 
instruments. Probably the best example of this is the change from a solid hydrogen Dewar to a Cryo-cooler that cools the 
MIRI instrument to its operational temperature. About a year after the MIRI PDR had been completed there was a late 
change in the architecture. The Dewar had also gone through its PDR at that point. This immense change almost had no 
effects on the MIRI Optical System development. The reason for this was that the interface to the Dewar was kept very 
simple and minimal. There was only a single point of interface, which was versatile enough to be used for the Cryo- 
cooler as well. 

Some further examples of the realized process are described in the following paragraphs. 

Much time was spent early in the ISIM program negotiating strut interfaces to structure and overall envelope. The most 
problematic area was near the Si’s pickoff mirrors where real estate was tight. It was, and still is, difficult to correlate 
models between ISIM team and Instrument teams, where each organization has different CAD programs (i.e. Pro 
Engineer™ vs IDEAS™). Also, configuration management of the models was a slow and cumbersome process. The SI 
development teams were rapidly updating their models as they designed their hardware and frequently the ISIM team 
was working with models that were 1 to 1.5 years old from the last contractual model delivery. 

There was an exhaustive effort put forth to accommodate “cones of light” for a ground based test system that was 
intended to verify optical alignment of the OTE-ISIM assembly during ground test, but needed significant real estate in 
the area of the Si’s pickoff mirrors. This effort was severely limited by the design stage of the instruments. The 
instruments had hardware already designed and was currently being built. All of the Sis made every accommodation 
possible for the cones of light as the ISIM mechanical team attempted to find sufficient clear paths (which included 
alignment uncertainties) for the test cones of light. In the end, the telescope test team deleted the cones of light in favor 
of a different test scheme. 

The Optical-Mechanical interface, such as SI interface motion relative to the telescope’s focal surface, pupil shear, 
system optical quality and transmission have been difficult to parse out over the various mechanical interfaces. It was 
the philosophy from the inception of JWST to require the Sis to meet a certain sensitivity level. From this sensitivity 
level and all of their given interface conditions, such as ISIM temperature range, the range of optical wavefront 
parameters at the telescope’s focal surface, electrical noise and system jitter, the Sis were to derive their own optical 
train performance and detector performance needs. However, the one exception to this was the NIRCam instrument. 
NIRCam is to be used as the telescope’s wavefront imager and therefore needed to have an agreed-to as-built optical 
distortion. These agreements were difficult to determine as the Observatory wavefront sensing requirements were 
extremely immature and essentially unknown at the time the NIRCam instrument performance requirements were 
generated. Recently, the wavefront sensing team has determined the need to use images from the other Sis for the 
Observatory’s wavefront sensing algorithms. Since all of the Sis are designed and now being built, the effort has 
centered on using the as-built design of the instruments in the algorithms. This is one example of a non-ideal 
requirement flow on the JWST program. 

There are still various optical performance interfaces that are immature. These include outgassing, ice, pickoff mirror 
adjustability and performance at higher temps for commissioning. The outgassing of the Sis during the first hours after 
JWST launch can severely impact the overall performance of all of the Sis by reducing the throughput of optics and 
causing increased stray light and ghosts. Contamination prevention heaters were added to the Sis to prevent ice 



contamination accumulation on the instruments during cooldown of the composite ISIM structure, which will outgas 
water at high rates above 140K. These heaters will keep the Sis warm until the structure is below 140K, but this will not 
prevent contaminants other than water from accumulating on the optics of the Sis that are open to the ISIM environment. 

To prevent volatile, non- water, contamination during the initial launch and cooldown, the materials located within the 
ISIM enclosure will have to be sufficiently depleted of their volatile components prior to cooldown. This requires all of 
the materials to be outgassed during a vacuum bakeout test prior to launch. The difficulty in developing these 
requirements early in the program was due to the uncertainty of the thermal model predictions of observatory 
temperatures during this portion of the mission. The amount of material within the ISIM enclosure due to immature 
harness and other support subsystems was also unknown at this time. The first attempt at defining requirements on the 
Sis was driven by contamination accumulation on the telescope’s fine steering mirror during Observatory cooldown. 
This mirror is not part of the ISIM but is located at the telescope’s entrance to the ISIM enclosure. The outgassing 
requirements were fairly tight based on this modeling effort. Subsequently, a cooldown control heater was added to this 
mirror to keep it warm until the ISIM structure was cold enough to freeze out contaminants emanating from it. 

The second generation of the outgassing modeling effort identified the outgassing requirement driver as the amount of 
contamination accumulated on the instruments pickoff mirrors while the instrument are warm at initial launch thermal 
conditions. The outgassing rate requirements generated by this analysis may still be overly conservative since the 
thermal analysis of this early timeline of the observatory is very conservative. Recent updates to the thermal models are 
proving useful outgassing rate modeling for the instruments. However, further refinement of this outgassing model may 
still reduce the maximum acceptable outgassing rates that will be required of the instruments. The goal is to reduce the 
values to ones similar to the what the instruments need to meet their own sensitivity requirements. This is a typical 
example where the early requirement generation was difficult or overly conservative due to the immaturity of other 
interfaces. 

Since the optical performance of JWST was specified at operational temperature, there exist few or no requirements on 
the performance of the system at other temperatures. The desire for warmer performance requirements comes from the 
concern of getting cold enough during ground testing as well as the desire to perform checkout and calibration of the 
instruments prior to them reaching their final cold state on-orbit. The design of the Sis at operational temperatures 
should not be degraded to increase performance at warmer temperatures, but it would be helpful to have it characterized. 
This characterization, however, would increase the testing time of the Sis at considerable expense. The observatory level 
analysis of the on-orbit cool down of the instruments has been slow in development and has yet to provide a clear need 
for extensive sub-system level testing at warmer temperatures. This is another example of a non-ideal requirement flow 
due to immaturity of higher level interfaces. 


5. REVIEW PROCESS 

The review approaches of the two organizations, NASA and ESA, are very different. The NASA review process includes 
a detailed set of presentations to a board of seasoned industry experts. Some of these experts are independent to the 
project and some may be part of the project from different areas of expertise. Over a period of days the architecture and 
development status is explained to the reviewers. A question and answer period is provided for each presentation and, as 
required, any additional discussion may be performed outside of the planned review. Any insufficient information, areas 
that may need more attention or things that have not been investigated at all are flagged and Requests For Action (RFA) 
are generated for the project to investigate. These actions are then answered through studies, and provided to the 
reviewers that generated the action. If the answer to the action is sufficient then the action is closed either with or without 
changes. 

ESA takes a different approach, with the reviews based almost entirely on document review. For any given review a 
predetermined set of documents is provided to the selected review team with a thirty day review period. The review team 
comprises experts from all organizations involved as well as independent reviewers. The review team is broken into 
groups based on their disciplines and each document is assigned to a member to review and generate comments. 
Comments are submitted on Review Item Discrepancies (RIDs) forms. At the end of the thirty day period all RIDs are 
scrubbed and the ones that seem to be valid comments against the documents are kept and the rest are discarded. A 
meeting is organized to go through each comment with the product developer. Any RIDs that can be explained on the 
spot are closed; detailed actions are generated that will allow each of the rest of the RIDs to be closed. 



Both review processes have certain shortcomings unique to each other. The NASA process relies on the information 
given by the presenters. The limited time for the presentation may result in cutting details from the presentations. It 
does not require a review of the documents, analyses, or other material to make sure they are consistent within each 
other. It is not possible to present every detail in several days, which means that shortfalls in the design may escape the 
reviewers’ attention. On the other hand the ESA reviews are solely making sure that the documents are consistent with 
one another. If there is anything wrong with the design and the documentation that is not part of the review, it is 
impossible to comment on to draw attention or assign actions. Since the documentation is divided up for each reviewer to 
comment on, it is not conducive to each reviewer weighing in on each aspect of the product. The ESA review process 
makes it difficult to review the system architecture or “big picture” approach. 

In an attempt to reduce the concerns and possible weaknesses of each review method, a unique review style was 
developed for the MIRI CDR, which combined the best aspects of both methods into one. A three day review to go 
through the design of the instrument in a presentation style was provided at the end of 2006. During the presentation 
there were actions generated as would be in a NASA style review. On the fourth day the review documentation package 
was provided to the reviewers with a thirty day review period. All RIDs or RFAs generated through both processes were 
scrubbed at the end and actions to be carried out were agreed upon at the end of the thirty day period. This seemed to 
have worked well with minor setbacks, which can further be optimized in the future. This style minimizes the possibility 
of overlooking important issues. The drawback of this approach is that it consumes more than a month of reviewer’s 
time, which costs precious resources and valuable time that could be spent to resolve issues already at hand. 

This approach can be optimized such that the review period for the documents could be kept shorter with a smaller list of 
documents that are essential, or with a number of intermediate reviews to go over the documents for consistency before 
the main review. 


6. CONCLUSION 

With the scheduled completion of the ISIM CDR in the Fall of 2008, the definition phase of the ISIM, its instrument 
compliment, and other key subsystems is concluding. This definition phase has been challenging due to the time phasing 
of the science instruments, the nature of international negotiations, the impact of programmatic and technical changes, 
and the differences in approach by the large number of organizations involved. Despite these challenges, a consistent 
and valid set of performance and interface requirements has been defined and will be carried through the development 
stage. A modification to the NASA defined system definition process has been presented as this process was realized 
given both internal and external constraints. As the testing begins in the integration and verification phase, the ISIM, 
instrument, and observatory systems engineering teams will be working closely to demonstrate adherence to the defined 
requirements. 
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